@benarena is there any payload claims data that shouldn't be in the headers? I'm wondering if at this point it would be easier to provide a blanket claims -> x-wallet-* mapping of sorts and do away with all the custom config for each field (maybe instead providing a config for a "header prefix" defaulting to "x-wallet-* as above mentioned).

@benarena is there any payload claims data that shouldn't be in the headers? I'm wondering if at this point it would be easier to provide a blanket claims -> x-wallet-* mapping of sorts and do away with all the custom config for each field (maybe instead providing a config for a "header prefix" defaulting to "x-wallet-* as above mentioned).

The JWT is not encrypted, so anything in the JWT can be safely added to the headers without fear of introducing a leak. Some claims are of questionable value (issuer, iat, exp), but certainly no harm in inclusion so long as the header name is comprehensible. x-wallet-iat may be confusing to the consumer.

Additionally, I'm happy to set a default header name rather than default to non-inclusion here if there is a preference for that. I've heard you'd like to split out the RBAC piece into its own plugin so it makes sense to make opinionated decisions related only to the verification and header inclusion in this plugin.